There is a need to supply file services to computers, such as a MPP machine and other clusters of computers, which form part of a network of attached computers which serve as a common computing resource.
We now have certain "open" (e.g. Xopen and POSIX) standards related to file data to a shared disk file system where computing jobs which will execute on various computers require access to the same file data as if the data was local to the computer executing the job (in order to run systems developed by IBM for different systems, see e.g. U.S. Pat. Nos. 4,274,139 and 5,202,971 and 5,226,159). When multiple computers are part of a network and multiple disks are part of the network, there is a need to create a shared disk file system which is compatible with the standards and yet requires no change in multiple instances of operating systems running on the computers, whether they are MMPs or clusters.
Shared File System (SFS) (see U.S. Pat. No. 5,043,876) is a term applied to IBM's S/390 systems which operate under IBM's VM for sharing data among virtual machines. Shared file systems also have been known as data sharing vehicles, such as IBM's IMS and GRS, where developed for a single-system environment, and under MVS GRS, was used in a cluster of systems sharing disk storage, and GRS in such a system could allocate small lock files on a shared disk in order to serialize access to data sets. MVS must serialize access to the table of contents on disks or to the catalog. Whatever RESERVES operations are needed for the operating system to perform causes a good deal of system overhead.
IBM's DB2 has been adapted for data sharing in a Multiple Virtual Storage (MVS) /Enterprise Systems Architectures (ESA) environment by using IBM's coupling facility to create multisystem data sharing which requires a System/390 Parallel Sysplex environment because the coupling facility is needed to deliver highly efficient and scalable data sharing functions where the coupling facility manages connections between processors with a message path mechanism, as outlined in U.S. Pat. No. 5,463,736, essentially becoming the super-single server for the shared data.
Represented by what may be the best of breed for Audio/Video file systems (IBM's VideoCharger Server for AIX), previous solutions dealing with computer systems which would allow standards compliance have relied on shipping file system level requests to a single server which acquires the data and returns it or shipping metadata requests from a client to a single server which allows the original computer to directly fecth the data. IBM also provides what is called the Virtual Shared Disk (VSD) program product which allows an SP2 user to configure nodes as primary and secondary IBM VSD server nodes. VSD software allows multiple nodes, running independent images of the operating system, to access a disk device physically attached only to one of the nodes as if the disk device were attached to all nodes, which IBM has implemented for the AIX operating system with a transparent switchover to a secondary server node when the primary server node for a set of virtual shared disks fails. In both cases, the existence of the single server is both a bottleneck and a potential failure point, even though there have been substantial advances made with such single server systems, like IBM's VideoCharger, as illustrated by U.S. Pat. No. 5,454,108's lock manager, U.S. Pat. Nos. 5,490,270 and 5,566,297's cluster arrangement. Also, as in International Business Machines' systems, there also exist capabilities for partitioning a disk accessed via a network so that a given computer manages and accesses a specific region of the shared disk and does not use the regions assigned to other computer(s).
However, these systems in the past have not provided any satisfactory solution permitting many computers which have a network access to multiple disks to permit any computer to have access to any data at any time, especially those which do not require a change in an operating system or standard, as we have developed and will describe in the context of our shared disk file system. Nevertheless, we must recognize the work done by the inventors of the U.S. Pat. No. 5,454,108 for their advances, for we have been able to use a modification of their lock manager as our advanced token manager in our own shared disk file system.